home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000042_owner-urn-ietf _Tue Mar 18 18:49:51 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  3KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id SAA03482
  3.     for urn-ietf-out; Tue, 18 Mar 1997 18:49:51 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id SAA03477
  6.     for <urn-ietf@services.bunyip.com>; Tue, 18 Mar 1997 18:49:48 -0500 (EST)
  7. Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA04976  (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Mar 97 18:49:47 -0500
  9. Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id SAA01107; Tue, 18 Mar 1997 18:49:45 -0500
  10. Date: Tue, 18 Mar 1997 18:49:45 -0500
  11. Message-Id: <199703182349.SAA01107@lysithea.lcs.mit.edu>
  12. From: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  13. To: urn-ietf@bunyip.com
  14. Subject: [URN] question #3 - management of usage
  15. Sender: owner-urn-ietf@Bunyip.Com
  16. Precedence: bulk
  17. Reply-To: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  18. Errors-To: owner-urn-ietf@Bunyip.Com
  19. Aside: 
  20.  
  21. This question brings up a point that Ron Daniel made to me recently.
  22. He suggested that we use abbreviation RDS for Resolution Discovery
  23. Service, rather than UDS.  I am completely comfortable with that.  It
  24. means that the abbreviation doesn't have "U" in it, which is probably
  25. a GOOD thing.  Also, the full name is shorter.  So, I will use that in
  26. this message and await comments, if any.  If there are none, the
  27. change will
  28.  
  29. Question: 
  30. The question really is two part: are controls needed on the behavior
  31. of customers of the RDS and if so, what sorts of mechanisms should be
  32. mentioned, given that any such mechanism will need to be incorporated
  33. into the protocols?
  34.  
  35. Background:
  36. In architecting a component of the infrastructure, we generally design
  37. for scalability, but there are always some constraints.  For example,
  38. a RDS may be intended to provide mappings from sets of URNs to
  39. resolution servers.  It may not be intended to map every URN
  40. individually into an RDS.  To engineer a global service that would map
  41. every URN separately and could provide any kind of tracking of changes
  42. seems unnecessarily difficult.  In addition, one might want to
  43. engineer for a certain level of update traffic.  Then the question
  44. that arises is how to cause users to behave approximately as expected.
  45. In the document I suggested a payment scheme of some sort.  Ron
  46. suggested that there were other alternatives, such as administrative
  47. control, although I don't quite understand how that would scale and
  48. distribute.  Hence the question to be addressed here.
  49.  
  50.  
  51. Comment:
  52. I have no strong opinions about this subject other than to believe in
  53. the tragedy of the commons, given no pressure on individuals to behave
  54. otherwise.
  55.  
  56.             Karen